Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reworking the runtime #263

Merged
merged 1 commit into from
Apr 9, 2024
Merged

Reworking the runtime #263

merged 1 commit into from
Apr 9, 2024

Conversation

davesmith00000
Copy link
Member

This PR may not survive, I'm just using it so it's easier for me to check my own work.

So far I've done some refactoring. No suggestion that this is an improvement, but the exercise has helped me reacquaint myself with what's going on.

The idea is to do the following, from the issue comment:

In this model you render on requestAnimationFrame, as long as you saw a message in the last, say, ~2 seconds. So if your app is idle, the rendering will go idle, but while stuff is happening (whether triggered by the user or anything else) the rendering continues.

Rough plan of attack:

Step 1 - Update pokes the renderer:

  • Remove ModelHolder
  • A model update triggers redraw
  • Redraw is on a Renderer class and returns a new instance (to be stored in a Ref?)
  • Render has a finite state machine: Idle, Running
  • When a redraw happens you record a timestamp, update the state to running (always, for now), then immediately render

Step 2 - Render runs on a loop (again):

  • Instead of the update poking the renderer and a render being triggered, it instead checks: if running do nothing, if not running, start render loop and set state to running
  • Render loop checks if < 2 seconds since last update, if true, loop, else state to idle and don't loop.

Something like that.

@davesmith00000 davesmith00000 self-assigned this Mar 28, 2024
@davesmith00000
Copy link
Member Author

davesmith00000 commented Mar 31, 2024

After going round and round trying to do this with CE, I decided just to PoC it imperatively to see if it was going to work at all. It kinda does.

My CPU has always seemed a little more eager than others have reported, so I wouldn't worry that the number seems to jump quite high in the gif, or that it's a little twitchy. This is similar behaviour to what I see on this machine from Elm apps.

Will need to verify on other machines.

<gif removed as I've noticed a bug> 🤦

Also, this is fast linked, not full linked.

@davesmith00000
Copy link
Member Author

Here you can see where the frame animations kick in when activity occurs, and drops off when the user stops doing work.

image

@davesmith00000
Copy link
Member Author

Screenshot from the Cats Effect version, which has replaced the imperative implementation.

image

@davesmith00000 davesmith00000 marked this pull request as ready for review March 31, 2024 14:51
@davesmith00000
Copy link
Member Author

If you have any free time to take a look at this @armanbilge, that would be great (don't worry if not 😄). This appears to do the trick but probably doesn't do it the nicest way.

@davesmith00000 davesmith00000 force-pushed the reworking-the-runtime branch from 208206d to dd11f7f Compare April 5, 2024 08:26
@davesmith00000
Copy link
Member Author

From my testing, this appears to be a vast improvement on pages that are idle between user interactions. I can't tell if there's any real impact on pages that do constant work - like games.

We don't have a way of defining "options" for Tyrian yet (like Indigo's GameConfig), but I'm wondering if it would be beneficial to be able to switch modes when you know what kind of site you've got. The "low consumption when idle" mode developed here could be a default.

@hobnob
Copy link
Member

hobnob commented Apr 9, 2024

This looks like it'll work in a vast majority of cases - as you say, I'm not sure about games, where the model might be updated a fair bit. That said - I think we should put it live as is, as I suspect most people will be using Tyrian for static sites, and Indigo for games. In my experience, even if you use Indigo for games and Tyrian as the UI, the actual amount of time you spend updating Tyrian's model is far far less than Indigo

Remove ModelHolder

A model update triggers redraw

Remove unused argument

Call redraw on a rendering class

Record last triggered time

Minor refactoring

Anemic Renderer

Revert "Anemic Renderer"

This reverts commit f297cb7.

Imperative version, but it kinda works.

Tidying up comments

Use the model Ref to use all updates

Replaced imperative impl with CE
@davesmith00000 davesmith00000 force-pushed the reworking-the-runtime branch from dd11f7f to 0980f66 Compare April 9, 2024 08:22
@davesmith00000 davesmith00000 merged commit f01dc29 into main Apr 9, 2024
2 checks passed
@davesmith00000 davesmith00000 deleted the reworking-the-runtime branch April 9, 2024 08:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants